per the docs the timestamp and tags are actually both optional so it shouldn't panic if there are no valid tags or a timestamp (and probably support optional timestamps as well)

The timestamp and the tags are now optional. This means it is now also allowed to not use any tags, which addresses #49.
Tests were added to verify the resulting online protocol string.

@poster515 thanks for posting the link to the docs and pointing this out.

But the behavior issue from above is still present when the following struct would be used:

#[derive(WriteDataPoint)]
#[measurement = "something"]
struct Item6 {
    #[influxdb(tag)]
    tag1: Option<String>,
    #[influxdb(field)]
    field1: String,
    #[influxdb(timestamp)]
    time: u64,
}

Here the field1 could be set to None which would lead to an invalid protocol string, because the string needs to include at least one field.
Some feedback on how this should be solved would be nice, or should we just ignore it for now and create an issue?

This seems like a question of "where should the fault occur?". The failure to write the point either happens in this code or at the influx server itself.

I kinda think simply not panicking and letting the write fail at the server is an easy approach but am not a maintainer lol

Thanks for the contribution and constructive discussion. I hope to give this a closer look later this week. I am leaning towards ensuring that at least 1 field is written and returning an Err if that isn't the case. I'd expect performance overhead to be acceptable. But I'd be happy to add that to this PR myself

Thanks for looking at the PR. It would be nice if you could add this to the PR, because I am currently traveling and won't have much time.

@UnHolds @Boudewijn26 Is this PR abandoned?

@LevBeta My apologies for my tardiness. I've been quite busy. I'll try to get to this soon